This invention relates to arrangements for routing telephone calls and more specifically, for such arrangements making use of a centralized database.
Telephone call routing has traditionally been accomplished through the use of small telephone numbers that specify a destination. In the North American numbering plan, a three digit area code specifies a region, a second three-digit code specifies a switching system within that region, and the last four digits specify a subscriber connected to that switch. The process of routing a call is thereby accomplished by routing the call to a toll switch within the specified region (and in some cases, using six-digit translation, to route the call to one of several such toll switches). Routing the call then, from that toll switch directly or indirectly to the switching system specified by the office code, and then, in that switching system, based on local translations, routing the call to the destination customer.
A number of problems with this simple arrangement have become apparent in the last several decades. For example, as xe2x80x9c800xe2x80x9d calling became popular, it was necessary that calls to an xe2x80x9c800xe2x80x9d number could be routed any place in the country. The problem was solved by implementing a database to translate from an xe2x80x9c800xe2x80x9d number to a conventional POTS, (plain old telephone service) number, and routing to that conventional telephone number. In a similar way, software defined networks were implemented to allow customers within a business to use an internal numbering plan to access other telephones of a business via the public switched telephone number by having a database to translate between internal telephone numbers, and POTS numbers.
The introduction of competition into the telecommunications business has further created problems. One of the desirable features that is being implemented with the introduction of competition, is local number portability wherein a customer may switch to being served by another service provider without changing the customer""s telephone number. Thus, a range of telephone numbers which formerly were associated with a single switch, may now be served by two or more switches. Proposed solutions to this problem have generally involved the use of a database to identify the switch serving a particular telephone number, and arranging to route the call to that switch, or by initially routing the call to the switch of the main carrier, and then re-routing the call to the switch of the carrier actually serving the terminating customer.
In recent years, the Internet network has grown. Using the facilities of the Internet network, an Internet name (e.g., e-mail address), or other handle is translated in a database into an Internet protocol address for transmitting Internet datagrams to the destination specified by the name.
Applicants have recognized that there are major shortcomings to the status quo for routing calls to a destination customer. First, translations are performed in all intermediate switches as a call is advanced from source to destination. The object of these translations is to determine the best route for connecting the call to the destination switch. Second, the process of providing telephone service to a customer that moves is costly, time consuming, and awkward. If the customer moves from one switch to another, the customer""s number generally is changed, which is undesirable. Even if the customer stays within the same switch, and/or retains the same telephone number, the administration of the change, and the change of translation data for that customer in a specific switch out of the hundreds of switches served by a service order bureau is time consuming; all the customer""s special service needs must be re-specified for the new switch and customer port. Whereas plans are being made which can accommodate number portability, within a selectively local area, the problems of allowing complete number portability throughout the nation are so formidable that practically speaking, nationwide number portability cannot be implemented using the present routing and translation arrangements. Third, special number blocks must be reserved for customers who have special terminating service, accessed by special access codes, such as xe2x80x9c800 numbers, and xe2x80x9c900xe2x80x9d numbers. The need for additional xe2x80x9c800xe2x80x9d numbers, for example, has already required the setting aside of two additional area codes for this purpose. Sometimes this has been helpful, since for example, customers know when dialing an xe2x80x9c800xe2x80x9d number they will not be charged for the call; however, as new, more specialized services are introduced, it will be awkward to require the setting aside of a new NPA code for each of these services. Fourth, the use of 800 and 900 numbers requires a special database dedicated to the function of translating to POTS numbers, a database which must be maintained along with the supporting local switch databases. Fifth, the current arrangement requires customers to be assigned one or more POTS numbers corresponding to 800, etc., numbers, thus using up these POTS numbers. Sixth, there is no facility for assigning a handle such as an Internet name to a customer being routed over the public switched telephone network, (PSTN). Seventh, special translations are required for routing calls to special announcements, mail boxes, call prompt menus, and services such as a xe2x80x9cmeet mexe2x80x9d conference switch.
Applicants have analyzed these problems and have come up with a generalized solution which represents a significant advance over the prior art. In accordance with their invention, a centralized database is consulted for routing calls; this centralized database makes a translation between an access identifier such as the called number, name or other handle, (e.g,. e-mail address), and a destination switch. In accordance with Applicants"" preferred embodiment, the translation further provides an identification of the terminating port or port group by means of which the destination switch can access the destination terminal. A port as used herein is an outlet from a switch that carries telecommunication signals to or from a user. It can be, for example, a line port connected to a customer line, a trunk port connected to a PBX, (Private Branch Exchange) or another switch, a port on a subscriber loop carrier, remote concentrator or remote switching unit connected to the terminating switch 1, a local area network port, or a radio link for accessing a wireless customer. Advantageously, using such an arrangement, a user can be connected to any switch regardless of the user""s access identifier.
In accordance with the preferred embodiment, calls to a number can be connected to a customer at any port of any switch, including a port for serving a wireless device. Advantageously, this permits customers who move to specify the new street address at which their telecommunications terminal is now connected; using a database to translate between any street address and the corresponding port and switch, by specifying a new street address to the database, the customer effectively specifies the switch and port to which calls for their telephone should be routed. The term xe2x80x9cstreet addressxe2x80x9d as used herein, also includes an internal apartment, room, or office number, for the case of a building occupied by multiple parties.
In accordance with one feature of Applicants"" invention, the full terminating translation is stored in the centralized database. Advantageously, this arrangement bypasses the need for a special translation from an 800 or 900 number to a POTS number, followed by routing a call using the POTS number. Instead the 800 number is translated to the identity of the terminating switch, and terminating port or port group. The translation can still provide the flexible arrangements for special access codes such as 800 or 900 number type calls which allow for variations in the selection of a terminating port, or port groups, according to the time of day, day of week, location, and/or identity of the calling party, traffic load, or language preference of the caller. Further, this type of arrangement offers the kinds of service previously available only to 800 or 900 numbers to customers with any number. Further, call forwarding service can be provided without first routing a call to the switch serving the home base of a customer.
In accordance with another feature of Applicants"" invention, calls to wireless devices can readily be completed. The database keeps track of the location where mobile customer""s device can be found. This is essentially the function performed by the VLR, (visitor location register), in the GSM, (Global Standard for Mobiles), standard. Using arrangement of Applicants"" invention, the database can route a call to the switch currently serving a mobile customer and that switch can be told the identity of the paging region wherein the customer""s device should be paged. Advantageously, this arrangement not only permits the centralized database to absorb functions of the VLR database, but also allows calls to be directly routed to the correct mobile switching center for completion of the call to the destination customer""s device.
In accordance with another feature of Applicant"" preferred embodiment, all service data of the destination customer which are pertinent to the routing and billing of the call are maintained in the database.
In accordance with another feature of Applicants"" invention, the originating class of service is maintained in the database. Advantageously, this arrangement allows all translation information for customers to be stored at the centralized database, and avoids the requirement for maintaining a customer database in each switch.
In accordance with another aspect of Applicants"" invention, if the called customer is served by a different network carrier, then the translation in the database provides the identity of the switch of this carrier that can be used to access the carrier which serves the called customer for calls to the requested destination, and the identity of the trunk group between the switch and that carrier that can be used for completing the call.
In accordance with another feature of Applicant"" invention, when a called customer is served by a different network carrier, the database maintains the busy/idle status of the in-service trunks, which may be spread over several switches, for accessing a desired access switch of the other carrier, and the database then selects the intercarrier access switch and the trunk of that switch to be used for this connection. Advantageously, no delay is incurred for falsely routing a call to a switch, all of whose access trunks are busy, and then re-routing the call to another switch.
In accordance with Applicants"" preferred embodiment, the single centralized database is realized as a distributed database. The partitions include partitions for subsets of customers. A different carrier is treated essentially as if it were a customer, and the database for that carrier customer maintains the busy/idle status of trunks for accessing that carrier customer, and the class of service for accessing that carrier customer.